COMMENT ⊗   VALID 00001 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂20-OCT-76  0944	RPG  
 ∂20-OCT-76  0403	JRA  	LISP
WHAT ARE YOUR FIRST IMPRESSIONS OF MANUSCRIPT? AND HOW FAR ALONG
ARE YOU? IF YOU WANT MORE, THE NEXT CHAPTER IS ALMOST READY.
					JOHN

	I am pretty much through chapter 2 (reading it fairly
carefully though), and have found some passages somewhat difficult
to understand (difficult in spite of the fact that I understand
what you are trying to get at). In particular, there is the section
on strictness/non-strictness/divergence etc. I have no specific complaints
about it , but I felt uncomfortable reading it the first time. I'm also
not too sure about the real advantage to the t/f vs. T/NIL decision. In some
sense, I view the ambiguity on LISP as one of its features. 
	I can take the next chapter whenever you are ready. I am planning
to really gung-ho it this weekend and be able to give back the commented
version I am reading.
				-rpg-

∂25-OCT-76  1043	RPG  
 ∂25-OCT-76  0358	JRA  	maclisp listing    
the last listing i caught was about 6.5 pounds; that was pre-bibop:1972.
if you can tell me where the file(s) exist, i can list them early in the
morning.
				john

	ok, the source will appear in 1,rpg by Oct 26. it will be called
lisp.nnn where nnn is something like 232.
	I am 3/4 done reading the parts i have and hope to finish tonight.
			-rpg-

∂25-OCT-76  1509	RPG  	MACLISP  
	WELL, JONL AND I ARE NOW TRYING TO FLUSH THE NON-BIBOP CODE,
SO IT IS NOT IN A GOOD STATE TO LOOK AT.
			-RPG-

∂28-Oct-76  2107	RPG  	BOOK
	I have finished the first part of the book and have the following
general comments:
	The parts on data structuring seemed to me to be forced. It may
be that I have some residual bigotry on my part, but I felt that it
didn't roll to easily.
	On the other hand, I felt that the sections on EVALuation and
spaghetti were among the best I have read in that area (i.e. excellent).
The implementations were quite understandable and the points were well
made. 
	More specifically, the comparison or analogy between mathematical
definitions and data structuring appeared to be very unnatural, although
I felt that the points made were good. 
	On spaghetti, my feeling is that it is undoubtedly something for
people who use LISP should know about, but it may not be something that
is ever useful in practice. I have personally never known anyone who has
used it in anything like a production program (except me), and almost none
who have even used it except to see how it works. It seems that there is
always a better way to achieve ones ends than by a general purpose &
inefficient features. Spaghetti invariably saves too much information, tends
to favor lexical variables (especially when you usually want fluid), and forces
laziness on the part of the hacker. For instance, I wrote a hairy pattern
matcher once which required real bactracking in a car/cdr recursion (not a
simple tree search). The matcher often had to bactrack into a control frame
that had been exited. Well, in LISP370 I used spaghetti, and in MACLISP I
explicitly used continuations, which clarified control and was fairly efficient
through the compiler. (the idea was to make the cdr recursion a sub-computation
of the car recursion as opposed to a sister computation). I plan to recode
the LISP370 version soon. 
	Another point concerns the use of continuations in the book. It
seems that they only appear briefly, as a passing concept between recursion/
subroutine returns and PC control. Well, either continuations should be
presented as a programming skill on its own, or it should be flushed as
a puzzling interlude, or some comment might be derived about its intermediary
position wrt stack control style and Program Counter style.
	I am always puzzled about the use of a "LISP Metalanguage" which is 
separate from the S-expression notation. I am not questioning the usefullness
of the metalanguage as a theoretical tool of great importance, but the 
of it as a pedagogical tool. When I TAed 206 for McCarthy, I saw the
bewilderment it caused when the two notations were introduced in parallel.
A point this "algolishness" seems to obscure is the natural ambiguity inherent
in LISP, namely between the program and the data. Now, I am definitely
not trying to say that it is the ability of LISP to write programs and execute
them which makes i such a nifty language, but that the ability to cons up
certain restricted expressions which can be later applied on a small scale
(that is the handles on the evaluator) that make it a useful language.
	A point that you don't seem to make is that LISP is an environment that
the user can sit inside of while his programs suffer trauma, and not a
compiler-based language in which you create your poooooor program, and boot
it into the confusing world of the compiler, tto suffer alone in the cruel
world.
	I guess LISP is naturally a hacker's programming language, in that
every nifty hook is available, and you can either hang yourself or not
according to your own abilities.
	An important aspect of any comprehensive discussion of LISP is why
it is that such an obscure looking language should be preferred by AI
hackers.
	Well, I look forward to the next sections of the book, and will
put the commented first part in your mailbox, if you have one, or mine.
				-rpg-